I. Abstract
Moving feature data can represent various phenomena, including vehicles, people, animals, weather patterns, etc. The OGC API — Moving Features (OGC API — MF) is a Draft Standard defining a standard interface for querying and accessing geospatial data that changes over time, such as the location and attributes of moving objects like vehicles, vessels, or pedestrians. The OGC API — MF provides a standard way to manage these data, which can be helpful for applications such as transportation management, disaster response, and environmental monitoring. OGC API — MF also includes operations for filtering, sorting, and aggregating moving feature data based on location, time, and other properties.
The OGC API — Moving Features — Part 1: Core specifies a set of RESTful web service interfaces and data formats for querying and updating moving feature data over the web. OGC API Standards define modular API building blocks to spatially enable Web APIs in a consistent way. OpenAPI is used to define the reusable API building blocks with responses in JSON and HTML.
The OGC API family of standards is organized by resource type.
Table 1 — Overview of Resources
| Resource | Path | HTTP Method | Document Reference |
|---|---|---|---|
| Collections metadata | /collections | GET, POST | Resource Collections |
| Collection instance metadata | /collections/{collectionId} | GET, DELETE, PUT | Resource Collection |
| MovingFeatures | /collections/{collectionId}/items | GET, POST | Resource MovingFeatures |
| MovingFeature instance | /collections/{collectionId}/items/{mFeatureId} | GET, DELETE | Resource MovingFeature |
| TemporalGeometrySequence | /collections/{collectionId}/items/{mFeatureId}/tgsequence | GET, POST | Resource TemporalGeometrySequence |
| TemporalPrimitiveGeometry instance | /collections/{collectionId}/items/{mFeatureId}/tgsequence/{tGeometryId} | DELETE | Resource TemporalPrimitiveGeometry |
| Queries for TemporalPrimitiveGeometry | collections/{collectionId}/items/{mFeatureId}/tgsequence/{tGeometryId}/{queryType} | GET | TemporalGeometry Query Resources |
| TemporalProperties instance | /collections/{collectionId}/items/{mFeatureId}/tproperties | GET, POST | Resource TemporalProperties |
| TemporalProperty instance | /collections/{collectionId}/items/{mFeatureId}/tproperties/{tPropertyId} | GET, POST | Resource TemporalProperty |
II. Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, OGC Moving Features, OGC Moving Features JSON, Moving Features Access, API, OpenAPI, REST, trajectory
III. Preface
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.
Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.
IV. Security considerations
The OGC API — Moving Features — Part 1: Core Draft Standard does not mandate any specific security controls. However, it was constructed to add security controls without impacting conformance, the same as the OGC API — Common — Part 1: Core.
This document applied the Requirement /req/oas30/security for OpenAPI 3.0 Security support.
V. Submitting Organizations
The following organizations submitted this Document to the Open Geospatial Consortium (OGC):
- Artificial Intelligence Research Center, National Institute of Advanced Industrial Science and Technology
- Université libre de Bruxelles
- Geomatys
- Central Research Laboratory, Hitachi Ltd.
- Feng Chia University
VI. Submitters
All questions regarding this submission should be directed to the editor or the submitters:
| Name | Organization |
|---|---|
| Taehoon KIM | Artificial Intelligence Research Center, National Institute of Advanced Industrial Science and Technology |
| Kyoung-Sook KIM | Artificial Intelligence Research Center, National Institute of Advanced Industrial Science and Technology |
| Mahmoud SAKR | Université libre de Bruxelles |
| Esteban Zimanyi | Université libre de Bruxelles |
| Martin Desruisseaux | Geomatys |
| Akinori Asahara | Central Research Laboratory, Hitachi Ltd. |
| Chen-Yu Hao | Feng Chia University |
1. Scope
The scope of the OGC API — Moving Features — Part 1: Core is to provide a uniform way to access, communicate, and manage data about moving features across different applications, data providers, and data consumers in contexts where the effects of Einstein’s relativity are not significant. The OGC API — MF defines a set of API building blocks that enable clients to discover, retrieve, and update information about moving features, as well as a data model for describing moving features and their trajectories.
The OGC API — Moving Features — Part 1: Core Draft Standard defines an API with two goals.
First, to provide access to representations of Moving Features that conform to the OGC Moving Features JSON Encoding Standard.
Second, to provide functionality comparable to that of the OGC Moving Features Access Standard.
The OGC API — Moving Features Draft Standard is an extension of the OGC API — Common and the OGC API — Features Standards.
2. Conformance
This Standard defines two requirements / conformance classes that describe different levels of compliance with the Standard. These requirements / conformance classes help to ensure interoperability between other implementations of the Standard and allow data providers to specify which parts of the Standard they support. The standardization target is “Web APIs”.
The conformance classes for OGC API — Moving Features are:
The conformance class defines the minimum requirements for an API to be compliant with the OGC API — Moving Features Draft Standard. This includes support for querying and retrieving information about moving features using HTTP GET requests. Also, the conformance class enables clients to add, modify, or delete features from the server using HTTP POST, PUT, and DELETE requests. Lastly, the conformance class adds support for querying and retrieving features based on their temporal characteristics, such as their position at a specific time or their velocity over a given time interval.
Implementers of the OGC API — MF can choose which conformance classes they want to support based on the specific needs of their use case and the capabilities of their software. However, to be considered compliant with the Standard, an implementation shall support at least the Core conformance class.
The URIs of the associated conformance classes are:
Table 2 — Conformance class URIs
| Conformance class | URI |
|---|---|
| MovingFeatures Collection Catalog | http://www.opengis.net/spec/ogcapi-movingfeatures-1/1.0/conf/mf-collection |
| MovingFeatures | http://www.opengis.net/spec/ogcapi-movingfeatures-1/1.0/conf/movingfeatures |
Conformance with this Standard shall be checked using all the relevant tests specified in Annex A of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing website.
3. Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
Policy SWG: OGC 08-131r3, The Specification Model — Standard for Modular specifications. Open Geospatial Consortium (2009).
Hideki Hayashi, Akinori Asahara, Kyoung-Sook Kim, Ryosuke Shibasaki, Nobuhiro Ishimaru: OGC 16-120r3, OGC Moving Features Access. Open Geospatial Consortium (2017). http://www.opengis.net/doc/is/movingfeatures-access/1.0.0.
Kyoung-Sook KIM, Nobuhiro ISHIMARU: OGC 19-045r3, OGC Moving Features Encoding Extension — JSON. Open Geospatial Consortium (2020). http://www.opengis.net/doc/IS/mf-json/1.0.0.
Clemens Portele, Panagiotis (Peter) A. Vretanos, Charles Heazel: OGC 17-069r4, OGC API — Features — Part 1: Core corrigendum. Open Geospatial Consortium (2022). http://www.opengis.net/doc/IS/ogcapi-features-1/1.0.1.
Charles Heazel: OGC 19-072, OGC API — Common — Part 1: Core. Open Geospatial Consortium (2023). http://www.opengis.net/doc/is/ogcapi-common-1/1.0.0.
Charles Heazel: OGC API — Common — Part 2: Geospatial Data (Draft). OGC 20-024, Open Geospatial Consortium, http://docs.ogc.org/DRAFTS/20-024.html
Panagiotis A. Vretanos, Clemens Portele: OGC API — Features — Part 4: Create, Replace, Update and Delete (Draft). http://docs.ogc.org/DRAFTS/20-002.html
E. Levinson: IETF RFC 2387, The MIME Multipart/Related Content-type. RFC Publisher (1998). https://www.rfc-editor.org/info/rfc2387.
E. Rescorla: IETF RFC 2818, HTTP Over TLS. RFC Publisher (2000). https://www.rfc-editor.org/info/rfc2818.
G. Klyne, C. Newman: IETF RFC 3339, Date and Time on the Internet: Timestamps. RFC Publisher (2002). https://www.rfc-editor.org/info/rfc3339.
T. Berners-Lee, R. Fielding, L. Masinter: IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax. RFC Publisher (2005). https://www.rfc-editor.org/info/rfc3986.
R. Fielding, J. Reschke (eds.): IETF RFC 7230, Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. RFC Publisher (2014). https://www.rfc-editor.org/info/rfc7230.
R. Fielding, J. Reschke (eds.): IETF RFC 7231, Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. RFC Publisher (2014). https://www.rfc-editor.org/info/rfc7231.
R. Fielding, J. Reschke (eds.): IETF RFC 7232, Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests. RFC Publisher (2014). https://www.rfc-editor.org/info/rfc7232.
R. Fielding, Y. Lafon, J. Reschke (eds.): IETF RFC 7233, Hypertext Transfer Protocol (HTTP/1.1): Range Requests. RFC Publisher (2014). https://www.rfc-editor.org/info/rfc7233.
R. Fielding, M. Nottingham, J. Reschke (eds.): IETF RFC 7234, Hypertext Transfer Protocol (HTTP/1.1): Caching. RFC Publisher (2014). https://www.rfc-editor.org/info/rfc7234.
R. Fielding, J. Reschke (eds.): IETF RFC 7235, Hypertext Transfer Protocol (HTTP/1.1): Authentication. RFC Publisher (2014). https://www.rfc-editor.org/info/rfc7235.
M. Nottingham, E. Wilde: IETF RFC 7807, Problem Details for HTTP APIs. RFC Publisher (2016). https://www.rfc-editor.org/info/rfc7807.
H. Butler, M. Daly, A. Doyle, S. Gillies, S. Hagen, T. Schaub: IETF RFC 7946, The GeoJSON Format. RFC Publisher (2016). https://www.rfc-editor.org/info/rfc7946.
M. Nottingham: IETF RFC 8288, Web Linking. RFC Publisher (2017). https://www.rfc-editor.org/info/rfc8288.
T. Bray (ed.): IETF RFC 8259, The JavaScript Object Notation (JSON) Data Interchange Format. RFC Publisher (2017). https://www.rfc-editor.org/info/rfc8259.
Open API Initiative: OpenAPI Specification 3.0.3, https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md
4. Terms and definitions
This document uses the terms defined in OGC Policy Directive 49, which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this document and OGC documents do not use the equivalent phrases in the ISO/IEC Directives, Part 2.
This document also uses terms defined in the OGC Standard for Modular specifications (OGC 08-131r3), also known as the ‘ModSpec’. The definitions of terms such as standard, specification, requirement, and conformance test are provided in the ModSpec.
For the purposes of this document, the following additional terms and definitions apply.
4.1. application programming interface (API)
an interface that is defined in terms of a set of functions and procedures, and enables a program to gain access to facilities within an application
[Source: Dictionary of Computer Science — Oxford Quick Reference, 2016]
4.2. coordinate
one of a sequence of numbers designating the position of a point
Note 1 to entry: In a spatial coordinate reference system, the coordinate values are qualified by units.
[source: ISO 19111]
4.3. coordinate reference system (CRS)
coordinate system that is related to an object by a datum
Note 1 to entry: Geodetic and vertical datums are referred to as reference frames.
Note 2 to entry: For geodetic and vertical reference frames, the object will be the Earth. In planetary applications, geodetic and vertical reference frames may be applied to other celestial bodies.
[source: ISO 19111]
4.4. dataset
collection of data, published or curated by a single agent, and available for access or download in one or more formats
[source: DCAT]
4.5. datatype
specification of a value domain with operations allowed on values in this domain
Examples: Integer, Real, Boolean, String and Date.
Note 1 to entry: Data types include primitive predefined types and user definable types.
[source: ISO 19103]
4.6. distribution
represents an accessible form of a dataset
Note 1 to entry: EXAMPLE: a downloadable file, an RSS feed or a web service that provides the data.
[source: DCAT]
4.7. dynamic attribute
characteristic of a feature in which its value varies with time
[source: OGC 19-045r3]
4.8. feature
abstraction of a real-world phenomena
Note 1 to entry: A feature can occur as a type or an instance. Feature type or feature instance should be used when only one is meant.
[source: ISO 19109]
4.9. feature attribute
characteristic of a feature
Note 1 to entry: A feature attribute can occur as a type or an instance. Feature attribute type or feature attribute instance is used when only one is meant.
[source: ISO 19109]
4.10. feature table
table where the columns represent feature attributes, and the rows represent features
[source: OGC 06-104r4]
4.11. geographic feature
representation of real-world phenomenon associated with a location relative to the Earth
[source: ISO 19101-2]
4.12. geometric object
spatial object representing a geometric set
[source: ISO 19107:2003]
4.13. leaf
<one parameter set of geometries>
geometry at a particular value of the parameter
[source: ISO 19141]
4.14. moving feature
feature whose position changes over time
Note 1 to entry: Its base representation uses a local origin and local coordinate vectors of a geometric object at a given reference time. [source: ISO 19141]
Note 2 to entry: The local origin and ordinate vectors establish an engineering coordinate reference system (ISO 19111), also called a local frame or a local Euclidean coordinate system.[source: ISO 19141]
[source: OGC 19-045r3]
4.15. property
facet or attribute of an object referenced by a name
[source: ISO 19143]
4.16. resource
entity that might be identified
Note 1 to entry: The term “resource”, when used in the context of an OGC Web API standard, should be understood to mean a web resource unless otherwise indicated.
[source: Dublin Core Metadata Initiative — DCMI Metadata Terms]
4.17. resource type
a type of resource
Note 1 to entry: Resource types are re-usable components that are independent of where the resource resides in the API.
[source: OGC 19-072]
4.18. trajectory
path of a moving point described by a one parameter set of points
[source: ISO 19141]
4.19. web API
API using an architectural style that is founded on the technologies of the Web
[source: W3C Data on the Web Best Practices]
4.20. web resource
a resource that is identified by a URI
[source: OGC 17-069r4]
5. Conventions
This section provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.
5.1. Identifiers
The normative provisions in this Standard are denoted by the URI
http://www.opengis.net/spec/ogcapi-movingfeatures-1/1.0
All requirements and conformance tests that appear in this document are denoted by partial URIs which are relative to this base.
6. Overview
6.1. General
The OGC API — Features Standard enable access to resources using the HTTP protocol and its associated operations (GET, PUT, POST, DELETE, etc.) The OGC API — Common Standard defines a set of features which are applicable to all implementations of OGC API Standards. Other OGC Standards extend OGC API — Common with features specific to a resource type.
This OGC API — Moving Features — Part 1: Core Draft Standard defines an API with the goal to:
Provide a standard interface for creating (HTTP POST), retrieving (HTTP GET), updating (HTTP PUT), and deleting (HTTP DELETE) Moving Features, with conformance to the OGC Moving Features JSON Encoding Standard (OGC 19-045r3).
Resources exposed through an OGC API may be accessed via a Universal Resource Identifier (URI). The URI representation in this Draft Standard is composed of three sections:
Dataset distribution API: The endpoint corresponding to a dataset distribution, where the landing page resource as defined in OGC API — Common — Part 1: Core is available (subsequently referred to as Base URI or {root}).
Access Paths: Unique paths to Resources.
Query Parameters: Parameters to adjust the representation of a Resource or Resources like encoding format or sub-setting.
Access Paths are used to build resource identifiers. This approach is recommended, but not required. Most resources are also accessible through links to previously accessed resources. Unique relation types are used for each resource.
Table 3 summarizes the access paths and relation types defined in this Standard.
Table 3 — Moving Features API Paths
| Path Template | Relation | Resource |
|---|---|---|
| Collections | ||
| {root}/collections | data | Metadata describing the Collection Catalog of data available from this API. |
| {root}/collections/{collectionId} | Metadata describing the Collection Catalog of data which has the unique identifier {collectionId} | |
| MovingFeatures | ||
| {root}/collections/{collectionId} /items | items | Static information of MovingFeature about available items in the specified Collection |
| {root}/collections/{collectionId}/items/{mFeatureId} | item | Static information describing the MovingFeature of data which has the unique identifier {mFeatureId} |
| {root}/collections/{collectionId}/items/{mFeatureId}/tgsequence | items | Sequence of TemporalPrimitiveGeometry about available items in the specified MovingFeature |
| {root}/collections/{collectionId}/items/{mFeatureId}/tgsequence/{tGeometryId} | item | Temporal object describing the TemporalPrimitiveGeometry of data which has the unique identifier {tGeometryId} |
| {root}/collections/{collectionId}/items/{mFeatureId}/tgsequence/{tGeometryId}/{queryType} | Identifies an Information Resource of type {queryType} associated with the TemporalPrimitiveGeometry instance | |
| {root}/collections/{collectionId}/items/{mFeatureId}/tproperties | items | Temporal object information of TemporalProperties about available items in the specified MovingFeature |
| {root}/collections/{collectionId}/items/{mFeatureId}/tproperties/{tPropertyName} | item | Temporal object describing the TemporalProperty of data which has the unique identifier {tPropertyName} |
Where:
{root} = Base URI for the API server
{collectionId} = An identifier for a specific Collection of data
{mFeatureId} = An identifier for a specific MovingFeature of a specific Collection of data
{tGeometryId} = An identifier for a specific TemporalPrimitiveGeometry of a specific MovingFeature of data
{tPropertyName} = An identifier for a specific TemporalProperty of a specific MovingFeatures of data
{quertyType} = An identifier for the query pattern performed by an implementation instance of the OGC API — MF.
Figure 1 shows a UML class diagram for OGC API — Moving Features (OGC API — MF) which represents the basic resources of this Standard, such as Collections, Collection, MovingFeatures, MovingFeature, TemporalGeometrySequence, TemporalPrimitiveGeometry, TemporalProperties, and TemporalProperty. In this Standard, a single moving feature can have temporal geometries, such as a set of trajectories. Also, the moving feature can have multiple temporal properties, and each property can have a set of parametric values.
